Add Profiles concepts page#9339
Conversation
This is a high-level introduction to OpenTelemetry profiles, setting the context and linking to the OTel eBPF profiling agent and the specification.
Now points to Profiles concepts page.
| Additional language-specific profiling integrations that tap into built-in | ||
| runtime profiling frameworks (e.g. JFR for Java, pprof for Go) will also become | ||
| available as the signal matures. |
There was a problem hiding this comment.
CC: @jhalliday Feel free to add extra information here.
There was a problem hiding this comment.
I think that's fine for now. I'm maintaining https://docs.google.com/document/d/1hrfElwEdoUQbj-fY0vVVN7kmWmlmn9F_eZzxMuVnVwo/edit?usp=sharing but it's not targeted at end-users. Once the OTel Java SDK has support shipping I'll do user docs for that and update to link from here I think.
| Profiles are emerging as the fourth essential signal of observability, alongside | ||
| logs, metrics, and traces. They offer unparalleled insights into system and | ||
| application behavior, often uncovering performance bottlenecks overlooked by | ||
| other signals. | ||
|
|
||
| Profiles provide granular, time-based views of resource consumption and code | ||
| execution, encompassing: | ||
|
|
||
| - **Application-level profiling**: Reveals how software functions consume CPU, | ||
| memory, and other resources, highlighting slow or inefficient code. | ||
|
|
||
| - **System-level profiling**: Offers a holistic view of the infrastructure, | ||
| pinpointing issues in operating system calls, kernel operations, and I/O. |
There was a problem hiding this comment.
I took this from the existing Profiles spec page as I think it provides better value here. I'll subsequently open a spec PR to update the Profiles spec pages.
theletterf
left a comment
There was a problem hiding this comment.
Good work. Any chance we could show what the profiling payload looks like?
|
|
||
| OpenTelemetry provides an | ||
| [eBPF-based profiling agent](https://github.com/open-telemetry/opentelemetry-ebpf-profiler) | ||
| for Linux, capable of profiling most languages with zero code changes. |
There was a problem hiding this comment.
| for Linux, capable of profiling most languages with zero code changes. | |
| for Linux, capable of profiling most languages with zero-code changes. |
There was a problem hiding this comment.
Are you sure about this? zero-code reads strange in this sentence (maybe it's fine if used as an adjective e.g. zero-code instrumentation).
If you prefer, I can reword this to "without any code changes"
Review feedback Co-authored-by: Fabrizio Ferri-Benedetti <fabri.ferribenedetti@elastic.co>
Review feedback Co-authored-by: Fabrizio Ferri-Benedetti <fabri.ferribenedetti@elastic.co>
Review feedback Co-authored-by: Fabrizio Ferri-Benedetti <fabri.ferribenedetti@elastic.co>
If you mean in terms of protobuf representation, I think it's best if we do this in the Profiles spec (where I'm working on two pages: README and data model that will present the format in detail). Trying to keep the concepts page more high-level, to serve as an introduction to OTel Profiles and give all relevant introductory context. |
|
@open-telemetry/profiling-approvers can we get a 👍 from one more profiling approver/maintainer, then this is probably good to go:) |
|
/fix:format |
|
✅ |
Summary
I took the Profiles overview from the current Profiles spec README and blended it into this PR. I did that as it doesn't really fit in the spec README and the high-level description it provides is much more suitable for the concepts page. I will subsequently open another PR to update and extend the Profiles spec page.
CC: @theletterf @open-telemetry/profiling-maintainers @open-telemetry/profiling-approvers
Footnotes
Yes, I can answer maintainer questions about the content of this PR, without using AI. ↩